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Abstract— Deep space missions beyond earth orbit will require 
new methods of data communications in order to compensate 
for increasing RF propagation delay. The Consultative 
Committee for Space Data Systems (CCSDS) standard 
protocols Spacecraft Monitor & Control (SM&OQ), 
Asynchronous Message Service (AMS), and Delay/Disruption 
Tolerant Networking (DTN) provide such a method. The 
maturity level of this protocol set is, however, insufficient for 
mission inclusion at this time. This prototype is intended to 
provide experience which will raise the Technical Readiness 
Level (TRL) of these protocols. 


In order to reduce costs, future missions can take advantage of 
these standard protocols, which will result in increased 
interoperability between control centers. This prototype 
demonstrates these capabilities by implementing a realistic 
space data system in which telemetry is published to control 
center applications at the Jet Propulsion Lab (JPL), the 
Marshall Space Flight Center (MSFC), and the Johnson Space 
Center (JSC). Reverse publishing paths for commanding from 
each control center are also implemented. The target vehicle 
consists of realistic flight computer hardware running Core 
Flight Software (CFS) in the integrated Power, Avionics, and 
Power (iPAS) Pathfinder Lab at JSC. 


This prototype demonstrates a potential upgrade path for future 
Deep Space Network (DSN) modification, in which the 
automatic error recovery and communication gap 
compensation capabilities of DTN would be exploted. In 
addition, SM&C provides architectural flexibility by allowing 
new service providers and consumers to be added efficiently 
anywhere in the network using the common interface provided 
by SM&C’s Message Abstraction Layer (MAL). 


In FY 2015, this space data system was enhanced by adding 
telerobotic operations capability provided by the Robot API 
Deligate (RAPID) family of protocols developed at JPL. RAPID 
is currently being adopted as an international standard by the 
CCSDS Telerobotic Operations Working Group. Gateways for 
the purpose of interfacing RAPID messages with the existing 
SM&C based infrastructure were developed. Telerobotic 
monitor, control, and bridge applications were written in the 
RAPID framework, which were then tailored to the NAO 
telerobotic test article hardware, a product of Aldebaran 
Robotics. 
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1. INTRODUCTION 


Spacecraft mission control centers are typically organized by 
agencies and missions. Generally, each center has unique 
interfaces to exchange mission services and products 
(Telemetry, Command, Planning, Navigation, Tele- robotics, 
and others.) These unique interfaces drive higher costs for 
integration and mission cross-support. 


The CCSDS Mission Operations Spacecraft Monitor and 
Control Working Group has been addressing these issues by 
developing a set of standards for interoperability. These 
standards are in various stages of development by several 
international space agencies, including NASA. AS 
standardized interfaces are included in mission operations 
centers, the cost for incorporating cross support and 
interoperability across agencies and missions will decline. 


The Space Data System prototype described in this paper 
demonstrates the ability to leverage services and reuse 
investments from several different centers on any given 
mission. Telemetry and Command services were 
implemented at the Protocol Test Lab at JPL, the Huntsville 
Operations Support Center (HOSC) at MSFC, and in the 
Operations Technology Facility (OTF) at JSC. This SM&C 
and DTN-based Space Data System was originally developed 
in the OTF in support of the DLR Prototype! and iPAS? 
Pathfinder activities, and was extended over DTN to support 
remote SM&C applications at JPL and MSFC. 


2. SPACE DATA SYSTEM OVERVIEW 


Figure 1 describes the general layout of this Space Data 
System prototype. 


Telemetry in the form of CCSDS Space Packets originates 
with the Multi-Purpose Crew Vehicle (MPCV) vehicle 
system in JSC Bldg. 29. Utilizing the Licklider Transmission 
Protocol provided by the Interplanetary Overlay Network 
(ION)’, the data stream is sent to a DSN Operations Center 
emulation in the JPL Protocol Test Lab. In the DSN Ops 
Center emulation, a 4 second one-way light time delay is 
applied, and 2% and 0.1% frame drop rates are modelled for 
the downlink and uplinks, respectively. The asymetric frame 
drop rates are due to higher power levels and larger antennae 
used by the ground sites. Utilizing the Asynchronous 
Message Service (again provided by ION) the data stream is 
then distributed to SM&C consumer applications in the OTF 
at JSC, the HOSC at MSFC, and in the Protocol Test Lab at 
JPL. Command services follow the reverse paths. 


Two observations can be made at this point. First, this is the 
only known Space Data System prototype based entirely on 
CCSDS international standards. Second, this is a realistic 
prototype for potential future DSN automation based on 
Delay/Disruption Tolerant Networking. 


3. SPACE DATA SYSTEM DETAILED DESIGN 
Figure 2 describes the Space Data System detailed design. 


A description of each segment follows. 
Flight Computer Segment 


Core Flight Software from the Goddard Space Flight Center 
runs on representative flight-like hardware in iPAS vehicle 
Bay 2, JSC Bldg. 29. An environment simulation generates 
sensor data, which is telemetered through the flight computer 
to the space-to-ground communications processor known as 
“datapub2.” The iPAS avionics suite contains an onboard 
power system, which processes commands relayed through 
the flight computer. A muffin fan is configured as the 
command target. Both telemetry and command data are 
formatted as CCSDS Space Packets, sent between 
“datapub2” and the flight computer over the User Datagram 
Protocol (UDP). 


Onboard Communications Processor Segment “datapub2” 


datapub2 hosts the onboard SM&C provider and Delay / 
Disruption Tolerant Networking processes. The SM&C 
Parameter Provider process ingests the CCSDS Space Packet 
telemetry stream from the iPAS flight computer. It then 
passes SM&C messages to the DTN process using the 
Asynchronous Message Service, which provides publish and 
subscribe functionality. AMS messages are then sent to the 
DSN Ops Center emulation at JPL using the Licklider 
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LIP is a 
connectionless protocol which provides automatic error 
detection and re-transmission. LTP is designed to support RF 
propagation delays on the order of interplanetary distances. 
The NASA Institutional Services Network (NISN) provides 
terrestrial connectivity. 


Transmission Protocol (LTP). reliable 


datapub2 also hosts the SM&C Action Provider, which 
receives command messages through the AMS / DTN 
ground-to-space link. The Action Provider generates CCSDS 
Space Packet command packets and forwards them to the 
flight computer for final relay to the onboard power system 
and the ECLSS fan. 


DSN Operations Center Emulation Segmemt 


Two main functions are implemented at the DSN Operations 
Center emulation in the Protocol Test Lab at JPL. The first 
is the space-to-ground link model, which applies a 4 second 
one-way-light-time delay, a 2% frame error rate on the 
downlink, and a 0.1% frame drop rate on the uplink. 


The second main function of the DSOC emulator is to anchor 
the ground side of the AMS / LTP / DTN link, and to then re- 
publish the AMS telemetry streams for distribution to 
geographically dispersed control centers. Both Simple 
Transmission Control Protocol (STCP) and datagram re- 
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transmission are used to provide reliable terrestrial links. 
Terrestrial links over UDP are also supported. 


Control Center Segment 


The original set of SM&C control center applications was 
developed in the OTF. The applications interface directly 
with the DSOC distribution node at JPL. The applications 
are used to display telemetry and command history, as well 
as initiating commands to control the onboard ECLSS fan. 


These applications, as well as the SM&C interface software, 
were then sent to the Protocol Test Lab at JPL, where they 
were compiled and installed. Telemetry display and 
command functionality are transparent between the PTL and 
OTF control center applications. Telemetry displays are 
identical at both control centers, as well as command 
capability. 


The same SM&C interface software was then sent to the 
HOSC at MSFC. In order to display telemetry, the HOSC 
“Display Dashboard” application was fitted with the SM&C 
common interface. The capability to easily add new 
parameters to the telemetry display was demonstrated. A 
new SM&C command application was developed, in order to 
generate ECLSS fan commands. Lines of text should be 
single-spaced, except for double spacing before headings and 
space-and-a-half after. 


Telerobotic Multi-Control-Center Architecture (FY ‘15) 
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4.TELEROBOTICS 


Figure 3 describes the multi-center telerobotic control 
architecture. 


A description of each segment follows. 
Robot Controller Segments 


The robot controller software module was developed in 
the Eclipse development environment, modified by JPL to 
include the Robot API Delegate (RAPID) telerobotic monitor 
and control protocols. The controller consists of views of 
robot joints and temperatures, battery charge level, onboard 
camera views. The controller has the ability to command 
each joint separately, and to activate pre-programmed 
behaviors and postures. The controller includes the RAPID 
Access Control module, which is used to coordinate robot 
control authority between multiple centers. As Figure 3 
shows, multiple instances of the robot controller can be 
executed simultaneously. 


The Eclipse / RAPID development environment uses 
Data Distribution Service (DDS) as its transport layer. 
RAPID commands and telemetry are expressed as DDS 
messages. 
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SM&C Controller Gateway Segments 


The SM&C controller gateway segments were 
introduced in order to interface the DDS based RAPID 
messages with the SM&C based Multi-Center Space Data 
System. The controller gateway simply encapsulates DDS 
messages into SM&C messages. 


Deep Space Network Segment 


The DSN segment is the Multi-Center Space Data System 
described in sections II and II. 


SM&C Bridge Gateway Segments 


The SM&C bridge gateway extracts DDS messages from the 
SM&C messages transported over the DSN segment. 


The RAPID / Robot Bridge Segment 


The RAPID / robot bridge segment performs the final 
step of converting RAPID standard messages (over DDS) 
into robot specific commands, using the software 
development kit provided by the robot manufacturer. 


5. OBSERVATIONS 


This prototype is end-to-end, in that SM&C and AMS 
processes are executed onboard, as well as the ground. This 
has an impact on both onboard software complexity and flight 
computer resource utilization. A hybrid configuration is 
possible in which SM&C and AMS processes are restricted 
to ground resources. 


This “all SM&C” configuration offers the advantage of 
architectural flexibility, in which SM&C consumer and 
provider processes can be located anywhere in the network. 
This has been demonstrated in the iPAS, in which identical 
consumer processes have been executed both onboard and on 
the ground. 


This prototype Space Data System has run continuously over 
the past two years. As the software has matured, system 
stability has improved. Unplanned outages have become 
rare. 


6. SUMMARY 


This project has shown that space mission information can be 
distributed to multiple control centers using standard 
Spacecraft Monitor and Control services. At the control 
center endpoints, local applications can then be easily 
integrated into the SM&C and DTN infrastructure. When 
standard protocols such as SM&C and DTN are utilized, 
interoperability increases, and both per-mission and control 
center costs decrease. Since these are internationally 
standardized protocols, international interoperability can 
increase as well. 


Interaction with the iPAS Pathfinder Lab has provided the 
opportunity to operate this multi-center Space Data System 
in a realistic scenario where light-time delay becomes 
significant. iPAS visibility has provided the opportunity to 
promote the acceptance and application of these 
internationally standardized protocols. This will contribute 
to raising their Technical Readiness Levels, and eventual 
incorporation into mission architectures and Deep Space 
Network re-design. 


APPENDICES 
A. ACRONYMS 


CCSDS =Consultative Committee for space Data Systems 
CFS = Core Flight software 


DDS = Data Distribution Service 

DSN = Deep Space Network 

DTN = Delay / Disruption Tolerant Networking 
GSFC = = Goddard Space Flight Center 

HOSC = =Huntsville Operations Support Center 
ION = Interplanetary Overlay Network 

iPAS = integrated Power, Avionics, and Software 
JSC = Johnson Space Center 

JPL = Jet Propulsion Laboratory 


LTP = Licklider Transmission Protocol 


MAL = Message Abstraction Layer 

MSFC = Marshall Space Flight Center 

NASA = National Aeronautics and Space Administration 
NISN  =NASA Institutional Services Network 
OTF = Operations Technology Facility 
RAPID = Robot API Delegate 

PTL = Protocol Test Lab 

RF = Radio Frequency 

SM&C_ = Spacecraft Monitor and Control 

TCP = Transmission Control Protocol 

TRL = Technical Readiness Level 

UDP = User Datagram Protocol 
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